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Abstract 

This  paper  reports  on  our  initial  results  in  using  Ada  as  a  Hardware  Description  Language.  Ada 
provides  abstraction  mechanisms  to  support  the  development  of  large  software  systems.  Separate 
compilation  as  well  as  nesting  of  packages,  tasks,  and  subprograms  allow  the  construction  of 
modular  systems  communicating  through  well  defined  interfaces.  The  complexity  of  modern  chips 
(e.g.  those  proposed  in  the  VHSIC  program)  will  require  the  use  of  those  features  that  make  Ada  a 
good  language  for  orogramming-in-the-large, 

The  key  to  our  approach  is  establishing  a  writing  style  appropriate  to  the  objective  of  describing 
both  the  behavior  and  the  structure  of  hardware  components.  We  model  a  hardware  system  as  an 
ensemble  of  typed  objects,  where  each  object  is  an  instance  of  an  abstract  data  type.  The  type 
definition  and  the  associated  operations  are  encapsulated  by  a  corresponding  package.  In  this  paper 
we  illustrate  our  approach  through  a  series  of  examples,  building  up  a  hypothetical  hierarchy  of 
hardware  components.  We  conclude  by  discussing  ways  to  describe  arbitrarily  complex  simulation 
models  and  synthesis  styles. 

1  Introduction 

The  work  that  load  to  this  report  started  in  response  to  a  DoD  request  for  proposals  to  design  a 
Hardware  Description  Language  for  the  Very  High  Speed  Integrated  Circuit  (VHSIC)  program.  After 
analyzing  the  requirements  we  found  that  Ada1  [ANSI,  1983]  could  be  a  powerful,  cost-effective 
hardware  description  language  since  it  provides  abstraction  mechanisms  to  support  the  development 
of  large  software  systems.  Separate  compilation  as  well  as  nesting  of  packages,  tasks,  and 
subprograms  allow  the  construction  of  a  modular  system  communicating  through  well  defined 
interfaces. 

A  desire  for  a  hardware  description  language  should  not  obscure  the  strong  commonality  of 
approaches  and  techniques  between  designers  of  complex  hardware  and  software  systems.  While 
the  full  power  of  Ada  may  not  seem  appropriate  for  the  design  and  specification  of  small  components, 
the  design  of  moder  chips  (e.g.  those  proposed  in  the  VHSIC  program)  will  require  the  use  of 
advanced  complexity  management  techniques.  We  argue  that  these  techniques  are  directly 
supported  by  those  features  of  Ada  which  make  it  a  good  language  for  programming-in-the-large. 

We  hasten  to  add  that  what  we  are  proposing  is  Ada,  not  an  Ada-like  language.  We  are  not 
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contemplating  the  writing  of  a  special  compiler;  any  off-the-shelf  Ada  compiler  will  do.  We  are  not 
even  proposing  adapting  or  modifying  some  existing  Ada  support  system;  any  validated  Ada 
implementation  will  do2. 

1.1  Description  of  the  Approach 

We  model  a  hardware  system  as  an  ensemble  of  typed  objects,  where  each  object  is  an  instance  of 
an  abstract  data  type.  The  type  definition  ana  the  associated  operations  are  encapsulated  by  a 
corresponding  package.  Thus,  each  package  manages  a  particular  kind  of  hardare  component  (e.g., 
wire,  nand  gate,  multiplexor).  The  public  operations  of  each  package  include  object  creation,  object 
construction  (from  its  component  parts,  interconnection  of  those  parts,  and  association  of  these  parts 
with  the  outer  object’s  interface  pins),  and  simulation.  The  semantics  of  these  operations  are 
explained  in  later  sections. 

Central  to  cur  representation  of  hardware  objects  are  the  dual  concepts  of  behavioral  and  structural 
views  of  a  hardware  description.  For  example,  a  multiplexor  may  be  described  behaviorally  as  an 
object  that  selects  among  a  list  of  inputs.  Alternatively,  it  can  be  described  as  a  collection  of 
interconnected  nand  gates  (in  a  multiplexor  configuration,  of  course).  A  behavioral  description  is 
generally  a  more  abstract  view;  it  hides  structural  details  which  introduce  implementation  decisions. 
The  structural  description  includes  only  the  information  about  an  object’s  components  and  their 
interconnections.  The  behavior  implied  by  a  structural  description  is  determined  by  the  behavior  of 
its  components  and  by  the  way  they  are  interconnected.  Behavior  is  not  intrinsically  "higher"  than 
structure  since,  at  the  lowest  level,  some  components  are  taken  as  primitives;  their  structure  is 
hidden,  and  their  description  is  purely  behavioral.  In  fact,  as  we  shall  see  in  some  of  our  examples, 
mixing  structural  and  behavioral  descriptions  at  the  same  "level"  can  be  used  to  enhance  the 
descriptive  power  of  the  notation,  making  the  intentions  of  the  designers  more  apparent. 

1 .2  Elements  of  Style 

Discussions  about  programming  styles  often  degenerate  into  theological  arguments  (witness  the 
long  standing  arguments  about  indentation  and  capitalization  of  keywords  and  identifiers).  We  do  not 
pretend  to  say  that  the  style  we  have  used  in  our  examples  is  the  best  or  that  it  should  adopted  by  all 
users.  As  a  matter  of  fact,  the  examples  are  contrived  to  display  the  features  of  the  language,  at  the 
expense  of  having  perhaps  too  many  levels  in  the  hierarchy  of  components.  In  a  production 
environment  we  would  expect  say,  latches  and  flip-flops,  to  be  implemented  as  primitive  components 
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Actually,  we  do  not  need  the  full  language:  a  reasonable  subset,  containing  the  right  features  is  sulfirient.  Talk  about  Ada 
subsets  is,  however,  considered  heresy  in  sortie  circles  and  we  will  not  raise  this  point  again. 
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whose  descriptions  are  carefully  handcrafted  for  simulation  efficiency,  rather  than  to  be  implemented 
by  building  them  up  from  inverters  and  nand  gates.  In  addition,  to  save  space,  in  this  paper  we  have 
limited  ourselves  to  illustrate  our  approach  via  simple  examples,  although  we  have  explored  other, 
more  complex  descriptions  in  [Maloney  et  al.,  1985]. 

In  constructing  the  examples  we  have  followed  a  few  guidelines  to  emphasize  readability  and 
modularity  and  to  define  appropriate  layers  of  abtractions. 

Readability.-  The  complexity  of  many  hardware  systems  and  their  equivalent  software 
representations  requires  that  the  code  be  easily  understood.  We  do  rely  on  comments  and  the 
flexibility  Ada  provides  for  writing  extended  and  legible  identifiers.  Appropriate  selection  of  names  for 
variables,  types,  and  operations  are  also  important. 

Ada  permits  the  overloading  of  enumeration  literals  and  subprogram  names.  We  take  advantage  of 
this  to  reduce  the  names  of  distinct  identifiers  that  must  be  learned  by  the  user.  The  basic  operations 
needed  to  create,  construct,  and  simulate  hardware  components  have  the  same  identifier, 
independent  of  the  component  type.  The  language  provides  mechanisms  to  resolve  the  ambiguities. 

Modularity,-  We  define  this  as  the  ability  to  connect  objects  that  are  of  different  types  through 
compatible  interfaces.  The  strong  typing  in  Ada  prevents  the  kind  of  error  in  which  a  component  of 
the  wrong  type  is  used  by  mistake  (e.g.  passing  a  nand  gate  to  a  D  Latch  simulation  procedure).  To 
permit  the  connection  and  transfer  of  signals  between  components,  we  use  universal  interface  types 
(e.g.  pins  and  buses).  All  components  define  their  interface  in  terms  of  these  types. 

Lavers  gf  abstraction.-  We  define  this  as  the  ability  to  have  multiple  levels  of  representation  for  the 
structure  and  behavior  of  hardware  objects.  In  our  approach  we  use  packages  to  define  libraries  of 
abstract  types,  one  per  package.  Each  package  is  built  upon  types  and  operations  defined  in  other 
packages,  in  a  hierachical  fashion.  In  addition,  the  separation  of  specifications  and  bodies  for  these 
packages,  permits  the  use  of  multiple  versions  of  bodies  supporting  the  same  specification.  This  has 
important  advantages  in  that  we  can  quickly  "plug  in"  more  efficient  simulation  models  or  synthesis 
algorithms  or  design  rule  checkers,  etc.  without  ever  having  to  alter  a  client  package,  or  even 
recompile  it.  The  switch  happens  at  link  time. 
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1 .3  Overcoming  Language  Limitations 

Ada  was  not  designed  with  hardware  descriptions  in  mind,  thus  we  have  adopted  some  conventions 
to  overcome  two  shortcomings  in  the  language. 

Lack  of  Timing  Primitives.-  Ada  has  no  primitives  for  expressing  time  and  time-based  relationships. 
Mapping  a  hardware  description  written  in  Ada  to  actual  hardware  requires  either  that  the  hardware 
be  implemented  using  fully  asynchronous  circuitry,  a  practice  not  widely  advocated,  or  that  timing 
specifications  be  introduced  in  the  process  of  mapping  to  hardware.  The  direct- mapping  approach  is 
the  object  of  current  research  at  the  University  of  Utah  [Organick  et  at.,  1 984.] 

We  overcome  this  deficiency  by  building  into  the  packages  operations  that  perform  the  synthesis  of 
the  abstract  data  type  into  hardware,  incorporating  the  appropriate  synchronization  and  timing 
information.  Thus,  rather  than  counting  on  a  "smart"  compiler  to  decipher  the  designer’s  intentions, 
we  use  "smart"  programs  and  libraries,  where  these  intentions  are  explicitly  stated. 

Ada  does  not  treat  packages  as  first  class  objects.  Ada  packages  may  not  directly  model  hardware 
components  unless  such  packages  are  elaborated  at  compile  time;  they  cannot  be  created 
dynamically  as  values  that  can  be  assigned  to  variables  or  passed  as  parameters.  Ada  tasks  do  have 
some  of  these  desirable  features,  however  they  suffer  from  other  limitations  (e.g.  a  task  specification 
cannot  define  and  "export"  data  types,  constants,  or  objects,  only  entries.) 

This  is  an  unfortunate  but  not  unsurmountable  difficulty.  In  our  approach,  we  use  packages  to 
manage  instances  of  (first  class)  record  types  which  in  turn  model  hardware  components. 

2  Elements  of  the  Description  Language 

2.1  Representing  Connections 

Before  we  present  the  details  of  how  hardware  objects  are  represented,  it  is  necessary  to  address 
the  problem  of  intermodule  connections. 

The  relationship  that  exists  between  hardware  objects3  and  interconnections  is  many-to-one;  that 
is,  many  objects  can  be  connected  through  one  connection.  A  first  representation  of  this  relation 
could  have  each  object  reference  the  "wire"  to  which  it  is  connected.  For  example,  if  components  A, 
B  and  C  are  all  connected,  we  have  the  arrangement  depicted  in  Figure  1.  This  representation  is 
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Actually,  here  we  arc  referring  to  an  input  or  output  of  an  object.  For  example,  the  output  of  a  nand  gate. 


Figure  1 :  Three  components  connected  by  a  simple  wire 

adequate  for  most  situations.  Here  we  treat  the  wire  itself  as  an  object.  For  simulation  purposes,  the 
wire  object  can  have  a  value  attribute  that  could  be  set  and  read  by  the  components  that  it  "joins". 
Information  about  how  many  components  the  wire  is  connecting  can  also  be  maintained  in  the  wire 
object. 

The  deficiency  in  this  representation  becomes  apparent  when  we  allow  components  to  be 
connected  in  an  arbitrary  order.  In  that  situation,  we  must  be  able  to  connect  objects  that  are  already 
connected  by  wires.  Figure  2  illustrates  this  point.  In  connecting  components  A  and  C,  we  would  like 
the  resulting  configuration  to  have  one  wire  that  is  referenced  by  components  A,  B,  C  and  D.  To 
accomplish  this  requires  that  we  change  C  and  D  to  reference  wire_1  or  A  and  B  to  reference  wire_2. 
Note  that  either  of  these  operations  assumes  the  capability  to  find  all  references  to  a  wire. 

The  desire  for  freedom  in  the  order  that  connections  are  made  motivates  a  slightly  more  complex 
representation  of  wire  interconnections.  The  deficien  .v  oi  me  previous  simple  strategy  is  that  there  is 
no  way  to  reference  all  of  the  objects  connected  by  a  wire.  An  intermediate  "pin"  data  structure 
solves  this  problem  in  the  following  way.  If  a  wire  actually  establishes  connections  between  pins  of 
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Figure  2:  Two  components  already  connected  by  simple  wires 


objects,  it  can  reference,  through  a  linked  list  of  "pins",  all  of  the  "pins”  that  are  connected  to  it.  This 
is  illustrated  by  the  three  pins  connected  as  shown  in  Figure  3.  The  task  of  connecting  pins  that  are 
already  connected  thus  involves  trivial  linked-list  operations  to  reconfigure  the  interconnection  and 
merge  the  pin  connections  to  one  wire. 

To  support  the  abstractions  or  wires  and  pins,  we  have  written  a  package,  Pin_Mgr  that  declares 
wires  and  pins  as  data  types  and  defines  appropriate  operations  for  manipulating  objects  of  these 
types.  The  package  is  written  so  that  most  details  about  intermodule  connections  are  placed  in  the 
body  of  the  package  and  are  therefore  hidden  from  the  users  (the  complete  package  listings  appear 
in  the  Appendix).  The  public  operations  of  this  package  are: 

•  The  procedure  connect,  which  connects  two  pins  (i.e.  links  them  in  a  'wire'  list.) 

•  The  procedure  disconnect,  which  breaks  a  connection  (i.e.  removes  a  pin  from  a  'wire' 
list.) 

•  The  procedure  equate,  which  associates  an  internal  pin  of  an  object  with  an  external  pin 
(i.e.  brings  cut  an  internal  component  pin.) 


•  The  procedure  unequate,  which  undoes  an  equate. 

•  The  procedure  set_value,  which  sets  the  value  on  a  wire.  This  procedure  and  the 
following  function  can  be  used  for  simulation. 

•  The  function  value_of,  returns  the  value  of  (i.e.  level  on)  a  wire. 

•  The  function  fan_out,  returns  the  number  of  pins  connected  to  a  wire. 

The  strategy,  then,  in  building  and  connecting  components  is  to  provide  each  external  input  or 
output  of  an  object  (representing  a  component)  with  a  "pin”  that  can  be  used  in  connecting  the 
object  with  other  objects.  Pins  and  wires  are  not  limited  to  modeling  the  idealized  connections  in  our 
sample  package;  physical  attributes  such  as  capacitance,  delays,  loads,  distances,  locations,  etc.  can 
be  easily  described  as  "attiibutes"  of  (i.e.  fields  of  the  record  types  modeling)  pins  and  wires. 
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2.2  Representing  Buses 

A  bus  can  be  described  as  an  array  of  pins,  using  conventions  similar  to  those  of  a  pin.  A  package 
supporting  this  abstraction  is  listed  in  the  Appendix.  The  visible  operations  of  the  Bus_Mgr  package 
are: 

•  The  procedure  connect,  which  connects  two  internal  buses  (provided  the  buses  have 
the  same  width.) 

•  The  procedure  unconnect,  which  breaks  a  connection. 

•  The  procedure  equate,  which  associates  an  internal  bus  of  an  object  with  an  external 
bus  of  the  same  width. 

•  The  procedure  unequate,  which  undoes  an  Equate. 

•  The  procedure  set_value,  which  sets  the  value  on  a  set  of  wires,  again  as  long  as  the 
width  is  the  same. 

•  The  function  value_of,  which  returns  the  value  of  a  set  of  wires. 

The  strategy,  then,  in  building  and  connecting  components  is  to  provide  each  external  input  or 
output  of  an  object  with  buses  or  pins  that  can  be  used  in  connecting  the  object  with  other  objects. 

2.3  Representing  Hardware  Objects 

We  can  identify  three  possible  approaches  to  the  problem  of  representating  hardware  objects  as 
typed  data  objects. 

The  first  approach  is  to  declare  hardware  objects  as  totally  "private"  (in  the  Ada  sense).  All 
operations  on  objects  are  defined  by  a  set  of  procedures  and  functions  that  involve  such  objects,  but 
nothing  about  the  objects’  structure  is  visible  outside  these  procedures.  Here  problems  arise  when 
attempting  to  interconnect  such  objects,  since  we  have  no  knowledge  about  an  object’s  interface. 

The  other  extreme  is  to  declare  hardware  objects  as  totally  "public"  (again,  in  the  Ada  sense). 
However,  this  method  exposes  information  about  an  object’s  structure  that  is  irrelevant  for 
connecting  the  object  with  another  object. 

The  third  approach  is  a  combination  of  the  previous  two:  we  represent  hardware  structures  using 
data  types  that  contain  both  public  and  private  parts.  The  public  part  of  an  object  contains  its 
interface  information  only,  while  the  private  part  contains  implementation  details,  The  example  in 
Figure  4,  shows  the  (public)  specifications  for  D  flip  flops. 


9 


type  d_ff_components  is  private; 


type  d_f 1 ip_flop_record  is 


record 
--  inputs 
dbar  :  pin; 
clkbar  :  pin; 
clear  :  pin; 
cl ock  :  pin; 

—  output 
qbar  :  pin; 

—  private 
components  ;  d 
end  record; 


—  Input  data  s 
--Input  clock 
--Input  signal 

— Clock  signal 

--Output  data 
_f  f_components ; 


ignal  d  (inverted), 
signal  (inverted)  to  run  slave 
to  clear  the  flip-flop, 
to  run  master  latch. 

signal  q  (inverted). 


1 atch . 


Figu  re  4:  Structure  of  the  D  Flip-Flop 


In  the  example,  the  components  field  of  the  D  Flip-Flop  record  is  a  component  of  a  private  type. 
Although  it  is  visible  as  a  record  component  outside  its  enclosing  package,  its  structure  is  private. 
Alternatively,  the  publically  visible  fields  of  an  object  could  be  defined  as  the  discriminants  of  an  Ada 
private  record  type,  with  the  hidden  parts  declared  in  the  full  type  declaration,  in  the  private  part  of  the 
package  specification.  With  this  approach,  not  even  the  components  field  is  visible  outside  the 
package.  The  drawback  is  that,  in  Ada,  the  values  of  discriminant  fields  cannot  be  modified  except  by 
a  full  record  assignment. 

2.4  Operations  on  Objects 

Now  we  will  describe  how  to  use  a  hardware  data  object,  that  is  to  instantiate  it,  to  establish  its 
functionality,  arid  to  simulate  it.  To  begin  this  process  one  must  first  create  the  object.  The  function 
create  allocates  storage  to  hold  values  for  a  component’s  interface. 

Once  a  data  object  has  been  instantiated  we  may  perform  other  operations  on  it,  such  as 
construct  and  simulate.  The  construct  procedure  establishes  a  structural  description  of  the 
object  by  creating  and  connecting  the  object’s  subcomponents. 

Once  the  function  create  and  optionally  the  procedure  construct  have  been  invoked,  objects  are 
ready  to  be  simulated.  For  each  object  type  that  we  define,  we  provide  a  simulate  procedure.  This 
procedure  operates  upon  information  that  is  placed  on  the  input  pins  to  produce  the  results  on  the 
output  pins.  Objects  at  the  lowest  design  level  (primitive  objects)  are  simulated  by  executing  their 
behavioral  description. 
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An  object  can  either  be  simulated  directly,  by  executing  a  simulate  procedure  that  implements  its 
behavior  or  indirectly,  by  executing  a  simulate  procedure  that  invokes  the  procedures  that  simulate 
the  subcomponents.  Details  of  the  algorithms  used  to  simulate  or  construct  objects  are  hidden.  The 
subprogram  specifications  only  describe  the  types  of  the  parameters  and  the  results. 

Using  this  approach,  mixed-level  simulation  is  easily  implemented  (A  similar  approach  to  mixed  level 
simulation  using  Simula  67  is  described  in  [Lindsirom,  1983]).  The  order  of  simulation  of  components 
should  begin  with  the  input  pins  and  follow  the  flow  of  new  data  throughout  the  network  of 
components.  Once  all  of  the  components  have  been  simulated  the  appropriate  output  values  will  be 
placed  on  the  output  pins. 

3  Shift  Register  Example 

This  section  presents  a  complete  example  of  the  specification  of  a  composite  hardware  object  (i.e. 
an  object  that  has  subcomponents.) 

Our  specification  of  a  shift  register  (National  Semiconductor  MM  74C168  [National,  1981])  is  built 
bottom-up.  We  begin  by  creating  certain  low-level  components,  namely  2-  and  3-input  nand  gates  and 
inverters,  described  by  packages  named  Two_lnput_Nand_Gate_Mgr, 
Three_lnput_Nand_Gate_Mgr,  and  lnverter_Mgr,  respectively.  These  packages  define  primitive 
objects.  Primitives  have  inputs  and  outputs  and  only  a  behavioral  description;  they  are  not 
represented  by  inter-connected  subcomponents. 

The  package  supporting  the  abstraction  of  an  inverter  declares  two  data  types  and  two  operations. 
The  data  types  describe  an  inverter  as  a  record  with  two  fields,  the  input  and  output  pins  respectively. 
Since  inverters  (as  well  as  other  gates)  are  easier  to  handle  as  Ada  access  (i.e.  pointer)  types,  the 
operations  defined  on  inverters  do  not  take  an  inverter  record  directly  but  rather  they  manipulate 
pointers  to  inverter  records. 

The  create  operation  is  used  to  instantiate  an  inverter.  Since  this  is  a  primitive  component,  there  is 
no  need  to  create  and  connect  internal  components,  as  we  shall  see  in  later  examples.  The  simulate 
operation  computes  the  value  at  the  output  pin,  depending  on  the  value  at  the  input  pin.  Notice  that 
we  are  ignoring  internal  delays;  these  are  idealized  inverters. 

The  package  supporting  the  abstraction  of  a  nand  gate  is  described  as  a  generic  package.  This 
permits  the  definition  of  nand  gates  of  arbitrary  number  of  inputs  by  simply  instantiating  the  generic 
package,  with  the  right  parameter  (the  number  of  input  pins),  without  having  to  rewrite  the  type  and 
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operation  declarations.  The  input  pins  are  modeled  by  a  dynamic  array  of  pins,  whose  dimension  is 
specified  when  the  generic  package  is  instantiated. 

Using  these  component  definitions,  we  can  establish  a  structural  description  for  a  D  Latch.  (See 
Figure  5.)  The  package  D_Latch_Mgr  package  establishes  the  structural  description  of  D  latches  by 
creating  and  interconnecting  an  inverter  and  four  nand  gates  whenever  the  construct  procedure  (in 
the  D  Latch  package)  is  invoked. 


Figu  re  5:  Inside  view  of  the  D  Latch. 


In  the  definition  of  the  D  Latch  record  type,  we  are  hiding  from  the  users  of  the  abstraction  the 
nature  of  the  implementation  of  the  latch.  That  is,  only  the  input  and  output  pins  are  directly  available. 
The  fact  that  there  are  components  is  revealed  by  the  definition  of  the  components  field;  however, 
since  this  field  is  declared  to  be  of  a  private  type  (o_latch_components),  no  user  of  the  package  can 
make  assumptions  about  its  structure. 

In  addition  to  the  create  and  simulate  operations,  the  D  Latch  package  also  provides  a  construct 
operation.  This  operation  must  be  invoked  after  a  D  Latch  has  been  created  and  before  it  can  be 
simulated.  It  builds  the  latch  by  instantiating  the  internal  components,  connecting  them  in  the  right 
configuration,  and  equating  some  internal  component  pins  to  the  input  and  output  pins  of  the  latch. 
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The  construction  of  components  continues  for  the  D  flip-flop,  the  next  level  up  in  this  component 
hierarchy.  The  package  D_Flip_Flop_Mgr  defines  data  objects  that  are  composed  of  D  latches  (See 
Figure  6.) 


ClockBar 


Clock 


OBar 


QBar 


CD 


Figu  re  6:  Inside  view  of  the  D  Flip-Flop. 


Notice  the  parsimonious  nature  of  our  approach.  Every  new  component  type  is  supported  by  a 
package  which  exports  a  record  type  and  an  associated  access  type;  this  permits  the  manipulation  of 
the  object  by  the  support  subprograms.  In  addition,  the  package  exports  procedures  to  create, 
construct,  and  simulate  the  component.  By  hiding  the  internal  structure  of  a  component  and  the 
implementation  of  the  operations,  the  designer  is  free  to  correct  or  enhance  the  abstraction,  without 
having  to  worry  about  amending  packages  that  import  the  abstraction  (provided  of  course,  that  the 
changes  do  not  affect  the  visible  part  of  the  abstraction.)  Any  hardware  system  built  out  of 
components  described  in  this  fashion  can  in  turn  bo  used  as  a  primitive  component  in  later  designs, 
provided  these  simple  rules  of  style  are  observed. 

As  with  the  D  latch  and  the  D  flip-flop,  the  serial  shift  register  (Figure  7)  is  constructed  by 
connecting  components  such  as  the  inverter,  nand2,  and  D  flip-flop  together  <n  the  correct  (graph) 
structure.  Once  constructed,  tbe  shift  register  can  be  simulated  by  invoking  the  procedures  that 
simulate  its  components. 
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Figure  7:  Inside  View  of  the  MM  74C168  Shift  Register. 


This  hierarchical  design  is  represented  in  the  compilation  dependency  graph  for  the  corresponding 
Ada  packages,  as  shown  in  Figure  8. 

4  Timing  Models:  An  Example 

In  the  preceding  examples  we  have  exhibited  the  power  of  the  language  to  describe  the  structure 
and  interconnections  of  hardware  components.  In  this  section  we  describe  how  it  is  possible  to 
implement,  within  the  same  framework,  arbitrarily  complex  timing  and  synchronization  models,  as  well 
as  synthesis  algorithms. 

By  way  of  example,  we  have  chosen  to  describe  how  the  element  of  delay  can  be  added  to  our 
library.  We  will  represent  time  after  the  CONLAN  model  of  computation  [Piloty  et  al.  1983].  CONLAN 
uses  the  notion  of  a  history  of  values  to  model  digital  hardware.  Computation  step  signals  correspond 
to  transient  values,  due  to  the  propagation  of  state  changes  in  the  system.  The  duration  of  a  step  is 
negligible  and  possible  intermediate  values  in  the  carriers  are  invisible  to  the  hardware  designer 
-•  only  the  final  value  of  a  step  signal  has  significance.  Time  signals  are  sequences  of  step  signals 
along  time;  one  step  signal  per  unit  of  time.  Time  signals  can  be  inspected  for  past  values  (the  last 
value  of  the  step  signal  associated  with  a  given  point  in  the  past)  as  well  as  current  values  (the  last 
value  of  the  current  step  signal). 
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Using  this  two-layered  model  of  time,  we  modify  our  simple  pin  package  as  shown  in  the  Appendix 
(under  "Extended  Pin  Specification"  and  "Extended  Pin  Body".)  Notice  that  in  addition  to  the 
additional  history  carried  by  a  wire,  we  have  added  an  extra  parameter  (delay_value)  to  the 
value_of  function.  The  function  now  returns  a  previous  value  of  a  signal.  We  can  now  use  this 
function  to  model  a  more  realistic  inverter  gate,  by  rewriting  the  simulate  function,  as  shown  in 
Figure  9. 


Notice  that  the  value_of  function  in  the  new  pin  package  specifies  a  default  for  the  delay_value 


procedure  S1mulate(v  :  In  1nverter_gate) 

—  Function: 

--  This  function  simulates  the  logic  of  an  Inverter  by  Inverting 

—  the  value  of  the  Input  pin  and  placing  the  value  on  the  output  pin. 
--  The  function  assumes  a  10-unit  gate  delay. 

Is 

begin 

case  Value_of(v. Input, 10)  Is 

when  low  ■>  --  If  Input  Is  low  the  output  Is  high. 

Set_value(v. output, high) ; 
return; 

when  high  »>  --  If  Input  Is  high  the  output  Is  low. 

Set_value( v . output , low) ; 
return ; 

when  others  ■>  —  If  Input  Is  undefined,  no  change 

null ; 

end  case; 
end  Simulate; 

Figure  9:  inverter  with  Internal  Delay 


parameter.  If  no  delay  is  provided  by  the  caller,  the  last  value  assigned  to  the  pin  is  returned  (i.e.  no 
delay  is  assumed.) 


In  this  example,  we  have  made  a  radical  change  in  the  package  supporting  the  abstraction  of  a  pin, 
yet  the  only  externally  visible  change  is  the  addition  of  one  extra  parameter  to  the  value_of  function. 
In  addition,  by  providing  a  default  value  corresponding  to  the  previous,  no-delay  version,  all  we  have 
to  do  is  recompile,  without  changes,  any  existing  library  packages.  That  is,  older,  idealized  (i.e. 
no-delay)  components  still  work;  new,  more  realistic  components  can  now  be  described,  and  both 
kinds  of  components  can  be  mixed  in  a  design. 


To  conclude  this  section,  we  point  out  that  in  our  approach  we  are  not  limited  to  using  pins  and 
internal  components  as  the  fields  of  a  record  modeling  some  hardware  component.  We  can  just  as 
easily  declare  fields  whose  values  correspond  to  physical  dimensions,  power  requirements,  locations, 
etc.  Since  the  process  of  constructing  components  is  done  by  calls  to  operations  defined  in  the 
library  packages  (create  and  construct),  it  is  rather  easy  to  keep  track  of  all  instances  of  these 
components  and  to  check  that  no  design  rules  are  being  violated.  The  data  structures  needed  for  the 
bookkeeping  provide  an  internal  representation  of  the  design:  translating  it  into  masks,  wire-lists,  or 
other  manufacturing  information  gives  us  the  path  towards  powerful  and  flexible  design  automation 
systems4. 

4 

As  powerful  and  flexible  as  the  code  we  are  willing  to  write,  and  wc  have  all  the  power  nf  Ada  to  do  this.  ..  Don't  be 
surprised,  the  emperor  in  the  fairy  tale  was  nakedl 
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5  Conclusions 

In  a  conventional  CAD  environment,  the  separation  between  the  user  and  the  toolmaker  is  very 
sharp.  Tools  (translators,  simulators,  synthesis  programs  etc.)  are  written  in  different  languages,  by 
separate  groups  of  individuals,  who  may  in  turn  be  distinct  from  those  in  charge  of  maintaining  the 
ensemble.  Users  are  bound  by  the  implementers’  decisions  (and  mistakes)  and  are  not  usually  in  a 
position  to  do  anything  about  them,  short  of  waiting  for  upgrades  or  fixing  the  problems  themselves. 
One  of  the  most  serious  deficiencies  with  this  conventional  approach  is  that  often  an  implementation 
will  bind  knowledge  about  a  particular  technology,  synthesis  style,  or  simulation  models  into  the 
implementation  in  such  a  way  that  it  is  often  not  possible  to  change  it  to  reflect  new  technologies  or 
better  design  methods. 

The  technique  we  are  describing  is  certainly  no  panacea;  errors  can  still  be  made.  However,  we  are 
eliminating  the  middle  men  and  exposing  to  the  users  (i.e.  designers)  the  full  implementation, 
technology  dependent  decisions,  timing  models,  and  synthesis  styles.  Since  the  implementation 
language  is  the  same  language  that  is  used  in  the  day-to-day  activities  of  the  designers,  they  can 
understand  the  source  of  the  problem,  can  propose  solutions,  and  finally,  can  implement  the  solution 
themselves,  without  further  ado.  Good  system  management  practices  will  probably  impose  some 
mechanisms  to  prevent  chaos  from  arising;  in  particular,  it  is  likely  that  only  expert  designers  will  be 
allowed  to  implement  such  changes.  Ada  provides  powerful  features  to  support  the  development, 
maintenance,  and  graceful  evolution  of  large  software  systems;  these  same  features  will  be  invaluable 
in  CAD  systems  of  the  80’s  and  beyond. 

The  advantages  of  using  the  same  language  for  both  the  design  of  hardware  and  software  are 
evident.  The  flexibility  in  delaying  the  binding  of  (hardware)  implementation  decisions  discussed  in 
this  paper  is  easily  extensible  to  a  more  basic  decision,  namely,  whether  a  portion  of  a  system  is  to  be 
built  in  hardware  or  in  software.  The  use  of  a  single  language  together  with  a  convention  on  style, 
permits  a  designer  to  write  an  abstract  interface  to  a  computing  engine  while  retaining  the  freedom  to 
implement  this  engine  in  either  hardware  or  software.  The  flexibility  continues  throughout  the  life- 
cycle  of  the  engine;  the  decision  can  be  reversed  at  a  later  time,  if  the  trade-offs  change,  without 
affecting  in  any  way  the  users  of  the  abstraction. 

In  addition  to  the  obvious  superiority  of  Ada  as  a  programming  language  over  existing  special 
purpose  hardware  description  languages,  there  are  other  reasons  why  Ada  is  an  attractive  hardware 
design  tool. 


Ada  is  a  standard  language  that  enjoys  the  support  of  the  largest  software  user  in  the  world,  the  U.S. 
Department  of  Defense.  Thus,  it  is  inevitable  that  rich  programming  environments  will  be  built  around 
Ada  and  that  the  community  of  users  will  be  several  orders  of  magnitude  larger  than  that  of  any 
existing  or  proposed  HDL.  Not  only  are  modern  software  development  technologies  easier  to  apply  by 
the  use  of  Ada  but  large  user  communities  provide  a  continuous  supply  of  tools,  methods,  training 
materials,  etc.  All  of  these  contribute  to  a  reduction  of  the  life  cycle  costs  of  a  project. 
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Function: 

The  specified  djatch  components  are  simulated  in  the  exact  order 
as  a  real  chip  would  operate. 
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Thu  is  an  abridged  u  man  of  ihepin  manager  package,  h  shows  only 
those  declarations  that  are  new  or  different  from  the  original  version. 
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